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ABSTRACT 

Ideas, requirements, and concepts developed during the very early phases of the mission design often conflict with the 
reality of a situation once the prime contractors are awarded. This happened for the James Webb Space Telescope 
(JWST) as well. The high level requirement of a common real-time ground system for both the Integration and Test 
(I&T), as well as the Operation phase of the mission is meant to reduce the cost and time needed later in the mission 
development for recertification of databases, command and control systems, scripts, display pages, etc. In the case of 
JWST, the early Phase A flight software development needed a real-time ground system and database prior to the 
spacecraft prime contractor being selected. To compound the situation, the very low level requirements for the real-time 
ground system were not well defined. These two situations caused the initial real-time ground system to be switched out 
for a system that was previously used by the flight software development team. To meet the high-level requirement, a 
third ground system was selected based on the prime spacecraft contractor needs and JWST Project decisions. The 
JWST ground system team has responded to each of these changes successfully. The lessons learned from each 
transition have not only made each transition smoother, but have also resolved issues earlier in the mission development 
than what would normally occur. 
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1. INTRODUCTION 

This paper is the result of experience gained in changing out the command and telemetry system in the JWST flight 
software I&T laboratory three times in the past one and a half years. The requirement to verify spacecraft flight 
elements early in a mission proposes a concept to reduce re- verification of database defined command, telemetry, scripts, 
displays, and ground system software. This implies the re-use of Database and Command and Telemetry (C&T) systems. 
If this is successful, the ground system and associated components will be verified early enabling the detection and 
correction of problems when the impact of the problem is relatively low and easier to repair. With a long-term program 
like JWST, this is a challenge. Maintaining a common ground system, from I&T that started in 2003 until real-time 
operations that will start in 2011, will require keeping various systems through many lifecycle changes. If you look at 
Commercial-Off-The-Shelf (COTS) changes in the base operating and hardware systems, these lifecycle changes will 
occur every 5 years. 

1.1 Background 


JWST is a large 6-meter aperture infrared space telescope with a 5-year mission (design goal 
of 10-years). JWST will continue the National Aeronautics and Space Administration 
(NASA) tradition of advancing breakthroughs in our understanding of the origins of the 
earliest stars by detecting the first starlight, plus other questions about the early universe 1 . 
The current launch date for JWST is 2011. 

The requirement to provide a common ground system for I&T, as well as operations, 
requires the deployment of the same system to fourteen different laboratories throughout the United States, Canada, and 
Europe, plus the Science and Operations Center to be located at the Space Telescope Science Institute (STScI) in 
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Baltimore MD. The JWST project involves many different groups in both private industry and government. The 
Goddard Space Flight Center (GSFC) is the lead NASA center for management and science instrument flight software 
development. For several reasons, the science instrument flight software development started prior to selection of a 
prime contractor (Northrop-Grumman Space Technologies (NGST)). The JWST ground system team, working with the 
science instrument flight software, the STScI, Integrated Science Instrument Module (ISIM) teams, and NGST, has 
integrated the various ground systems that have been selected by the JWST project into the I&T environment. 

1.2 Starting Point 

The JWST ground system team defined the scope of a common ground system for I&T and operations. The scope, 
shown in Figure 1, was determined to be only those systems that are common to both environments; the Common 
Command and Telemetry System (CCTS) and the Project Reference Database (PRD). 
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Figure 1 - Total Ground System for I&T and Operations 

Once the scope was determined the JWST ground system team determined the user needs, requirements, and currently 
available products. With the goal of providing the same system for I&T, as well as operations, the challenge is to find a 
way to predict the future and ensure persistent ground system components. These grounds system components will 
potentially span the timeframe of 2004 to 2021. If you look back in time, 17 years to 1987, and the changes that 
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occurred such as the Internet, high-speed networks, and even to products like Windows and Acrobat which were still in 
the development stages. 


2. HOW TO ACCOMPLISH THE COMMON GROUND SYSTEM GOAL 

The initial design for JWST was to implement a common ground system that would be used from I&T through mission 
operations. The ground system used for flight software I&T, mission I&T, and mission operations usually goes through 
an evolutionary process. This process adds and deletes capabilities that are unique for each phase and many times 
involves changes in the real-time displays, scripting language, and database process. JWST is focusing on the same 
ground system to be used in all phases of JWST development to reduce the cost and risk of these changes. 


In the JWST experience, prior to the selection of the prime contractor, the JWST flight software team needed a ground 
system to accomplish the requirement of validating flight software data early on in the mission. In order to facilitate 
this, it was determined through various commercial off the shelf (COTS) and government of the shelf (GOTS) product 
studies that the EPOCH 2000™ ground system would be delivered and implemented for use with flight software 
validation. Upon selection of the primary contractor, further cost and requirement studies were undertaken, coming to a 
final decision that the Eclipse ground system would be used as the JWST common ground system. It was determined 
that Eclipse wouldn’t be delivered until a year and a half after primary selection. This created a problem since flight 
software still needed to meet their validation requirements while at the same time the ground system needed to start 
migration towards a smooth transition to Eclipse. It was then determined that we would move from EPOCH 2000™ to 
ASIST™, a GOTS product, in order to achieve both of these goals. Eventually this would lead to a smoother transition 
into Eclipse as well as allowing the flight software team to continue JWST flight software validation. 

2.1 Requirements 

Throughout these various ground system migrations, the level 3 and level 4 requirements remained constant leaving the 
focus on changes in implementation that would need to be made for a selected ground system. During these migration 
periods, it was important to work with user groups months before the integration in order to verify their requirements 
would be met. This was accomplished by meeting with users, prioritizing changes that would need to be made to the 
ground system, and planning the ground system build schedule. As can be expected allocation of the requirements to the 
system that would implement it did change. The JWST ground system team did this allocation knowing the limitation 
COTS products and the team’s ability to create custom tools and applications to fill the voids. 


An example of the JWST ground system team meeting the requirements with a particular implementation can be shown 
in the JWST database implementation. The database will be needed for several systems, including the C&T system, 
simulators, planning systems, and archive systems. A database data interchange format (i.e., central database format) 
was determined that would allow for easy swap in and swap out of input and output products as the different ground 
systems elements are integrated into the ground segment. One of the main ways this was achieved was determining 
early on that the central database format would be in a standard non-proprietary format. The JWST ground system team 
negotiated the use of a data structure that works with multiple commercial products. In this way a single company going 
bankrupt or no longer supporting a product will not drastically affect the central database. JWST will be using 
extensible Markup Language (XML) for its structure; XML is supported by multiple vendors and allows for a non- 
proprietary self-describing data structure. XML has the capability to translate into unlimited number of formats, thus 
allowing for use by data consumer systems based on functionality, not driven by required format. Figure 2 shows the 
XML data system, showing all of the systems that can be integrated with the common data format. This includes, but is 
not limited to, real-time data viewers, data modification tools, data validation tools, simulators, and ground systems. 
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Figure 2 - Standard XML Workplace 


2.2 Philosophy of Ground System Architecture 

Current traditional NASA models are wide and varied between the various NASA centers/space projects. In general the 
spacecraft dictates many of the various flight operations ground segment elements. Also the various spacecraft 
development groups decide what tools and ground systems to use during their phase of development and long-term 
growth paths are not seriously considered in the early phases. The JWST ground system team, knowing that the systems 
needed a long-term plan, defined four philosophies in evaluating and determining what elements to use in the ground 
system. 


1) Use the same data - Separate the data structure, as much as possible, from the application using the data. 

2) Use COTS standards for software and maintenance - use the development personnel staff when products are 
needed 


3) Use modular components - minimize the impact when a particular system is upgraded 

4) Provide upgrade path from the beginning of the process - plan from the beginning changes in all systems 


With these in place the JWST ground system team divided the ground system into the various elements and organized 
them so the end users see a consolidated ground system as shown in figure 3. 


Also since the ground system will be used during I&T, in many different 
environments and locations, portability was key in hardware design. Another 
consideration for the hardware design was that some of the systems were going to be 
re-used by different groups. In order to maintain a simple design, that is easy to 
configuration manage, assure all the CCTS network connections remain constant, 
and is mobile, a short rack configuration that is completely self-contained was 
considered as the prime hardware design. 
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Figure 3 - CCTS ground system elements 
2.3 Evaluations of Available Systems 

Various trade studies 3 were done on the JWST ground system prior to a primary contractor being selected. These trade 
studies determined which system would be used during flight software development and flight software I&T prior to the 
common, Eclipse, ground system delivery. During these trades, 1 1 candidates were studied, eventually being narrowed 
to four systems: ITOS — A government developed system used on Small Explorers (SMEX), ASIST™ — A 
government developed system used for Middle Explorers (MIDEX), EPOCH™ — A commercially developed ground 
system and Control Center System (CCS) ground system developed for Hubble Space telescope (HST). 

In Phase One of the process, candidate products were identified and evaluated on key criteria related to capability, cost, 
performance, and risk. The evaluation data were collected through mission manager interviews with GSFC, John 
Hopkins University Applied Physics Laboratory, the United States Air Force, and through COTS vendor interviews, as 
well as COTS demonstrations at vendor sites. 


Altair Aerospace Corporation 
GSFC Code 584 
GSFC Code 442 
Raytheon Corporation 
Integral Systems Incorporated 


The products selected for Phase One evaluation were: 

• Altairis MCS ™ (COTS) 

• ASIST™ (GOTS) 

• HST Vision 2000 CCS (GOTS) 

• Eclipse (COTS) 

• EPOCH 2000 ™ (COTS) 
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• ITOS (GOTS) GSFC Code 584 

• SCL™ (COTS) Interface and Control Systems 

Three of these products; ASIST, EPOCH 2000, and ITOS were selected for detailed evaluation in Phase Two. 

Experience gained during Phase One interviews was used to focus the baseline real-time C&T requirements and 
operations concept. In Phase Two evaluation, the JWST ground system team sought answers to the following questions: 

• Wilt each product, as delivered, meet basic mission requirements? These were the following: 

Provides necessary functional capabilities 

Supports Development, I&T and Operations mission phases 

Supports operational concepts including Shuttle launch, L2 orbit, and automation for lights-dim operations 
Supports desired PC-based H/W platform 

Compatible with planned DSN Ground Station environment including CCSDS compliance 
Enables operator productivity with an intuitive, user-friendly interface and available tools 
Is mature; at least one previous mission 
Is stable, according to the experience of other users 

Is maintainable (based on open source or responsive vendor), has limited dependencies on other COTS, and 

has well-defined APIs for future expansion 

Is affordable in cost/benefit terms, with an upper limit on cost 

• What is the estimated cost and effort needed to modify each product to meet any of these requirements that it 
currently fails to meet? 

• What additional features does each product offer that might do any of the following? 

Increase ground system usability 
Decrease risk 
Decrease cost 

Phase Two products were installed at GSFC for an extensive hands-on, side-by-side comparison. Each vendor provided 
integration support and responded to evaluator questions, and the results for each product were discussed with the 
vendor to minimize misunderstandings. After extensive evaluation and testing the following high-level results were 
determined: 

• ASIST™ has a small number of evaluation criteria requiring additional software development, but suffers 
significantly larger hardware costs. 

• ITOS appears to have the lowest overall cost, and a small number of evaluation criteria requiring additional 
software development, but these items include the important planning and scheduling, command management 
and level zero processing functions. ITOS also lacks some of the features of ASIST™, particularly in the area 
of command verification. 

• EPOCH 2000™ is expected to require the most additional software development. Key functions requiring 
custom development include flight dynamics functions, planning and scheduling, command management, and 
level zero processing. 

The JWST ground system team found that each of the products (ASIST™, EPOCH 2000™ and ITOS) could adequately 
support basic mission requirements. Each product required a minimal configuration effort and only a small enhancement 
effort to meet all of the baseline requirements. While searching for real-time C&T components that supported JWST 
“right out of the box,” the reality is all C&T systems require modifications in order to work with any spacecraft. The 
development of the operations concept in parallel with the C&T component evaluation allowed us to focus on interfaces 
and broad capabilities. Side-by-side operation of the competing products allowed direct comparisons of capabilities 
despite their differing design approaches. 

The findings were that the ITOS and ASIST™ were not modular. They had no mission support past 2010, which created 
problems when looking at the long-term implications. To meet JWST requirements, it was recommended that the COTS 
package, EPOCH™, would be used. EPOCH™ had contracts going beyond 2010, was concurrently being used as the 
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I&T system, and was used by NOAA for real-time flight operations. The EPOCH™ architecture allowed for it to be used 
as a front end to other systems on the network. This modularity would allow EPOCH™ to be used as the basic C&T 
system, yet if it needed to be upgraded or changed, the impacts to the total Ground Segment would be minimal. 

EPOCH™ was selected as the first, of what would be come, several ground systems to be supported in the coming year. 
After the prime spacecraft contractor (NGST) was selected, a joint NASA/NGST cost and impact study between EPOCH 
and Eclipse determined that Eclipse would be the best candidate to meet the common ground system requirement. 
However, the Eclipse system would not be available to support JWST specific requirements for another year. To bridge- 
the-gap the flight software team elected to use the ASIST C&T system, which had previous heritage use and meets their 
immediate needs. 

With the schedules completed, the JWST ground system will go from EPOCH™ to ASIST™ to Eclipse all in the JWST 
flight software laboratory. The only system the other hardware, software, and operational users will experience is the 
Eclipse ground system. 

2.4 Changes in Systems 

Throughout the ground system development there have been changes that have needed to be implemented. Through 
each ground system iteration the requirements were reviewed, the capabilities analyzed, and the changes that would need 
to be implemented to meet the requirements were defined. Not only were changes based on ground system functionality 
defined through each iteration, but analysis was also performed to define which changes could be made to allow for a 
more efficient and less problem prone integration. This analysis has proven extremely helpful in the migration from one 
ground system to the next. It has allowed not only for a quicker integration, but also has allowed for possible problems 
to be solved even before the ground system delivery. One problem that might have taken months to solve, now takes 
almost no time at all since it is a problem that has been seen before. 

Upon completion of the use of EPOCH™, there was a detailed review that focused on the work that had been completed, 
problems that came up during the process, and things that were seen as positives. Two of the major problems that lead 
to many delays in implementing the changes and meeting the requirements was stakeholder concurrence on interfaces 
and the maturity of all system involved. Because the interfaces weren’t defined to a level of certainty, some of the 
ground system elements were being developed in a way that wasn’t compatible with the assumed interface. Scheduling 
problems also became apparent in the testing phase of products. The testing schedule didn’t accurately account for the 
maturity of the product, thus leading to schedules not being met, and future deliverables being pushed back. These were 
just some of the items that were later documented and solved for future implementations. These issues later lead to a 
more efficient integration of ASIST™ and Eclipse, including: 

• Defining and reaching consensus on interfaces between the ground system and data consumers. (This later lead 
to the development of the Data Formatter (DF) that will be used with Eclipse) 

• Defining a schedule for testing that is more realistic to the maturity of the products. (Ensuring system testing of 
COTS and GOTS is performed prior to receipt of the product so that testing focus in on end-to-end product 
configuration testing only) 

• Starting the translation of flight software scripts from one ground system language to another much earlier. 

• Maintaining a regular schedule of communication among flight software developers, flight software testers, the 
ground system team, and other stakeholders. 

Along with some of the challenges that were recorded and learned from, there were also many positives that came from 
working with the EPOCH™ ground system. To ensure that the ground system added onto each previous 
implementation, it was important to define and ensure the positive aspects that were implemented in the previous 
iteration were carried over into the next. Some of the key items that were ensured to remain intact were: 

• Responsiveness to new requirements: Eclipse had demonstrated similar responsiveness in previous NASA 
missions. 

• Hardware and network reliability (no failures): Eclipse will be delivered as a turnkey system. 

• Flexible and reliable scripting language: CECIL (Eclipse’s scripting language) is less flexible, but in a format 
more familiar to testers. (More “STOL” like) 
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• Seamless database propagation process: Eclipse database propagation process is well understood by ground 
segment parties, and Eclipse will perform standard XML-to-flat file translation. A Project Reference Database 
(PRD) working group has been established by the STScI to ensure stakeholder agreements with regard to the 
Data Interchange Format (XML) used to define the data within the PRD. 

• 

The carrying over of these lessons learned during the integration of each ground system is crucial in minimizing the 
problems that arise during ground system integration. 

3. CHANGING OUT ELEMENTS 

Layers of hardware and custom software are added to the Eclipse system by GSFC to comprise a composite system 
providing ISEM lab ground and flight support. This product is called the Common Command and Telemetry System- 
ISEM Ground Support System (CCTS-IGSS). 

3.1 Division of System 

Figure 4 shows how the various components of the common ground system are divided up for development and support. 
This division allows for custom tools that are often specialized and only needed in unique laboratories to be incorporated 

as part of the ground system. All 
category C items will be developed and 
maintained by those users needing 
these tools. The two remaining 
categories A and B will be delivered to 
each user as an integrated system. The 
only difference is that category A is the 
prime C&T system, all other systems 
integrated will be category B. 


ICD’s will provide concise description 
and format of the interfaces between 
each category or external element. 



Figure 4 - Category Divisions of Ground System Elements 
3.2 Category A Systems 

This category is the primary COTS C&T vendor. It was determined to have this category for ease of contractual and 
requirements definitions. By having the core real-time functions, as supported by the ECLIPSE™ system, as it’s own 
category allowed for clearly defined Interface Control Documents (ICD’s). This is helpful in minimizing costly changes 
to the core COTS C&T system. The ECLIPSE™ system includes some mission specific capabilities primarily in the 
areas of flight software event processing and ASCII commands. The Eclipse system processes and interfaces with all 
other ground system elements in the exact manner, as it will during real-time flight operations. 
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3.3 Category B Systems 

The various category B systems that are needed by all users of the CCTS are described below. The combination of 
category A and B provide all the common systems that are used for I&T, as well as flight operations. Additional 
capabilities needed for flight operations will be added to the system without changing the systems already in use. 

• PRD Tools - Provides support to ingest PRD data and generate run-time databases used by Eclipse or other 
tools that utilize PRD data items. Local configuration management and management of PRD data updates back 
to the central repository are also provided functions. 

• Load and Dump Tools - Provide the capability to manage ISIM Command & Data Handler (ICDH) data input 
to the CCTS such as memory, table and observation plan loads and dumps. This tool also provides comparison 
and reporting tools as well as Graphical User Interfaces (GUIs). 

• Data Formatter - Provides the capabilities to handle the receipt and transmission of command, telemetry, status, 
and control messages between Eclipse other CCTS elements. This tool limits the impact on Eclipse of changes 
to the various systems. 

• FITS Writer - Provides the capabilities to handle the receipt of files from the Solid State Recorder and format 
the science data into Flexible Image Transport System (FITS) for use by offline systems. 

• Activity Description Tool - Provides the capability to view, edit, and format the text activities to be uploaded to 
the ICDH computer. 

• File Server - Provides the capabilities for storing information from the various CCTS tools, providing 
documentation related to the CCTS, and providing an interface for outside users to drop off and pickup files as 
needed. 

3.4 Category C Systems 

The JWST ground system team realized reality within the design of the CCTS. Users in each of the various laboratories 
will have tools that have been used in the past that they will want to use again with the new system. All category C 
systems will get data using a defined ICD. In general, all data within the CCTS will be available to the category C 
systems. Real-time commanding to any flight hardware or simulators will only be allowed from the Eclipse system. 

3.5 Infrastructure 

The final piece in the CCTS is the supporting infrastructure. This piece is crucial in the tying together of all the tools in 
the system and providing a seamless “look & feel” to the product. This includes an already integrated network, a router 
with add-on capability, and administrative tools. This will allow the local labs to manage and add onto their CCTS 
network as they see fit, without the added overhead of integrating the tools together on their own. This will allow the 
local labs to focus on their task at hand, rather than complicated networking issues among the tools. It also minimizes 
the amount of support that will be needed by the ground segment team at the local labs, since the infrastructure will be 
integrated and tested prior to delivery. In addition, system software upgrade and troubleshooting can be performed 
remotely from either Goddard or the COTS vendor site. 

4. SUMMARY 

As the JWST ground system team responded to each change many valuable lessons were learned, eventually leading to 

the successful and efficient implementation of the common ground system. Although it 
took three iterations of ground system to reach the eventual common system, it was 
iLyi* fl through this migration effort that allowed for lessons to be learned much quicker than 
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would have been realized otherwise. This not only allowed for a more seamless integration of the final system, but also 
allowed for the ability to refine the design and implementation of the ground segment and it’s tools. 

Key elements that allow for changing out different ground systems with minimal impact are: 

Structure the database to be in a format that is independent of any application or ground system 
Decouple the interface of the C&T system with the remaining target systems, like simulators. 

Migrate tools that are custom developed for every COTS ground system, such as spacecraft loads and dumps, 
to be outside the C&T COTS software. 


Implementing these elements met resistance at first, but once the transitions from one C&T system to another 
progressed, the benefits became a point of pride. 

Although the initial reason for migrating through various ground systems was in order to meet flight software’s 
validation requirements, it eventually lead to a more robust system, with various configurable toolsets, better defined 
interfaces, and self-contained networks. 
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